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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the requirements and architecture for the Self Organizing Network (SON) functions 
within the OAM system. SON includes: 

Provision of infrastructure for SON, in the OAM system 

• Enabling SON operations 

• Provide SON capabilities (each of which can either be distributed or centralised) within the OAM 
infrastructure, including their management 

• Access to SON relevant eNodeB attributes 

• Identification of SON relevant eNodeB and UE Measurements 

• Access to and transfer of SON relevant eNodeB and UE measurements 

• Transfer of SON relevant eNodeB alarms 

Define necessary Interface IRPs 

- the automation of neighbour relation lists in E-UTRAN and between different 3 GPP Radio Access 
Technologies, 

- self establishment of a new eNodeB in the network, 

- self-configuration and self-healing of eNodeB s, 

- automated coverage and capacity optimisation, 

- optimisation of parameters due to troubleshooting, 

- continuous optimisation due to dynamic changes in the network, 

- automated handover optimisation, 

- optimisation of QoS related radio parameters. 

The SON concept and architecture are described in clause 4. 
The high-level requirements for SON are defined in clause 5. 
Use cases for SON are described in clause 5. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 32.501 : "Telecommunication management; Self-Configuration of Network Elements; 

Concepts and Integration Reference Point (IRP) Requirements". 

[3] 3GPP TS 32.51 1: "Telecommunication management; Automatic Neighbour Relation (ANR) 

management; Concepts and requirements". 

[4] 3GPP TS 32.521: "Telecommunication management; Self-Organizing Networks (SON); Self- 

optimization and self-healing; Concepts and requirements". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

Centralised SON : SON solutions where SON algorithms are executed in the OAM System. In such solutions SON 
functionality resides in a small number of locations, at a high level in the architecture. 

Distributed SON : SON solutions where SON algorithms are executed at the NE level. In such solutions SON 
functionality resides in many locations at a relatively low level in the architecture. 

Hybrid SON : SON solutions where part of the SON algorithms are executed in the OAM system, while others are 
executed at the NE level. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 



Concepts and background 



4.1 SON concepts 



As a consequence of flattening the access network architecture in E-UTRAN (due to removal of the RNC) it is likely 
that a network operator will require more Release 8 eNodeBs than Release 7 NodeBs in order to cover an equivalent 
geographical area. Network operators have also articulated their requirement to have more flexibility over the choice of 
eNodeB vendor, irrespective of the MME or NMS vendor. 

In order to reduce the operating expenditure (OPEX) associated with the management of this larger number of nodes 
from more than one vendor the concept of the Self-Organizing Network (SON) is introduced. Automation of some 
network planning, configuration and optimisation processes via the use of SON functions can help the network operator 
to reduce OPEX by reducing manual involvement in such tasks. In 3 GPP Release 8 many of the signalling interfaces 
between network elements are standardised (open) interfaces. Significant examples in the context of SON are the X2 
interface between eNodeBs and the SI interface between eNodeB and the EPC (e.g. MME, SGW). 

If the solution for a particular SON-related use case is best provided at the network level the associated SON 
algorithm(s) will reside in one or more network elements. This is an example of a distributed SON architecture. 

If the solution is best provided in the existing network management system or in an additional standalone SON function 
or server, then the SON algorithm(s) will most likely reside either at DM or NM level. This is an example of a 
centralised SON architecture. 

It may also result that the solution could require SON functionality partly at the network level and partly in the 
management system. This is an example of hybrid SON architecture. 

For 3GPP Release 8 it has been decided that SON algorithms themselves will not be standardised. 
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5 Business Level Requirements 

5.1 Requirements 
5.1.1 General 

REQ-SON-CON-01 SON solutions shall provide an easy transition from operator controlled (open loop) to 
autonomous (closed loop) operation, as the network operator gains more trust in the reliability of the SON. 

REQ-SON-CON-02 The SON Architecture and implementation should support network sharing between network 
operators. The impact of individual shared network topographies on proposed SON solutions shall be decided on a case- 
by-case basis. 

REQ-SON-CON-05 For operator controlled (open loop) SON function, the implementation of any update proposed by 
the SON function shall take effect only after a response by the Operator. 

REQ-SON-CON-06 For closed loop SON function, the implementation of any update proposed by the SON function 
shall take effect without the need for response by the Operator. 

REQ-SON-CON-07 An NE can operate with SON function or without SON function and can easily be transferred 
between these two modes. The ability to suspend/ resume/ enable/ disable the SON function shall be determined on a 
case by case basis. 

REQ-SON-CON-8 An IRPManager shall be able to monitor the specific results of each particular SON function 

5.2 Actor roles 

IRP Agent. The entity performing the agent role. 

IRP Manager. The entity performing the manager role. 

Network Operations Staff. During open loop operation, personnel who manually review the results of the SON 
function at intermediate steps in the particular SON process. The network operations staff decide upon and manually 
initiate the appropriate next step in the SON process. 

5.3 Telecommunications resources 

The managed network equipment. The particular equipment and the need for any SON function(s) within it will be 
specific to each individual use case. 

The OAM system. The location of any SON function(s) within the OAM system will also be specific to each individual 
use case. 

SON Function. The SON algorithm and associated processes that automatically determines the optimum 
configuration, connectivity, or installation parameters for a network element. 

5.4 High-level use cases 

A high-level use case diagram may be presented. In order to understand the use case by subject 

matter experts, they should be augmented with a textual description for each use case. 

The description should serve two purposes: to capture the domain experts 1 knowledge and to 

validate the models in analysis and design phases with respect to the requirements. 

An example of a high- level use case diagram is given in Appendix I of M. 3 020. 
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5.4.1 e-NodeB Sharing Use Case 



e-NodeB 

Sharing Use 

Case Use case 

stage 


Evolution/Specification 


«Uses» 
Related use 


Goal 


A new eNodeB shared by more than one Network Operator is successfully taken 
into service. The MME or MME Pool to which it is attached is aware that this 
eNodeB serves more than one operator. 




Actors and 
Roles 


Network Operator A - provides MCC/MNC information and provisions the 

eNodeB. 

Network Operator B - provides MCC/MNC information and gives provisioning 

information to Network Operator A. 




Telecom 
resources 


Planning tool of Network Operator A. 
Shared eNodeB. 




Assumptions 


A commercial relationship exists between the Network Operators. 




Pre-conditions 


Combined provisioning information from both Network Operators is available to 
be downloaded to the new eNodeB. 




Begins when 


The Network Operators agree to share an eNodeB. 




Step 1 (M) 


The operators exchange provisioning data. 




Step 2 (M) 


Network Operator A loads both sets of provisioning data into his Planning tool. 




Step 3 (M) 


The self-establishment process for installation of a new eNodeB retrieves the 
combined data from the Planning Tool. 




Ends when (*) 


The new eNodeB is in service and its associated MME or MME Pool is aware 
that it is a shared eNodeB. 




Exceptions 


None. 




Post-conditions 


Successful if: 

Provisioning data in the eNodeB matches that in the Planning Tool. 

MME or MME Pool is provided with correct information and can distinguish 

between the traffic from each Network Operator that shares the eNodeB. 

Unsuccessful if: 

Mismatch between provisioning data in Planning Tool and eNodeB. 

MME or MME Pool unable to identify either or both of the Network Operators as 

those which share the eNodeB. 




Traceability (*) 


Requirements or use case exposed by the use case. 


REQ-SON- 
CON-02 



5.4.2 Transition from Open Loop to Closed Loop Use Case 



Use case stage 


Evolution/Specification 


«Uses» 
Related use 


Goal 


The transition from the state where Network Operations personnel intervene and 
act as a manual control and authorisation point for outputs from a SON function, 
to a state where the outputs are used automatically and the personnel merely 
monitor without intervention. 




Actors and 
Roles 


Network Operations personnel - manually installing or updating information 

output from a SON function in the target node(s) via use of the planning tool or 

via the NM/DM at intermediate steps during the open loop phase of the SON 

implementation. 

SON Functions - automatically generating SON outputs for review by the 

Network Operations personnel during open loop operation or for automatic use 

during closed loop operation. 




Telecom 
resources 


Network Management System 
SON function. 




Assumptions 






Pre-conditions 


Initial SON information is defined manually by the network operator and is 
resident on the relevant target node(s). 

The Network Operations personnel defined manual intervention/pause point and 
forces the SON function to take effect only after a response/confirmation by the 
Operator. 

The SON is running in Open Loop. 


REQ-SON- 
CON-05[1] 
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Use case stage 


Evolution/Specification 


«Uses» 
Related use 


Begins when 


The Network Operator decides to transit from Open Loop to Closed Loop 
NOTE: The transition may only occur once the operator has gained trust in the 
reliability of the SON. 




Step 1 (0) 


The Network Operations personnel remove the manual intervention/pause point 

either all at once or gradually. 

The Network Operations personnel allow the SON function to run in Closed 

Loop 




Step 2 (M) 


The Network Operations personnel periodically monitor the automatically 
updated SON information and verify that network performance continues to meet 
or exceed planned targets. 




Ends when (*) 


The SON function operates in a closed-loop mode; the SON function takes 
effect without the need for response by the Operator 


REQ-SON- 
CON-06[1] 


Exceptions 


The Network Operator disregards the SON function and reverts to manual 
Operation of the Network without any intervention by the SON function, if the 
latter generates SON information that results in unexpected network 
performance. 




Post-conditions 


The SON function is in use and is automatically producing appropriate SON 
information for the target node(s). 




Traceability (*) 


Requirements or use case exposed by the use case. 


REQ-SON- 
CON-01 [1] 



ETSI 



3GPP TS 32.500 version 9.0.0 Release 9 1 ETSI TS 1 32 500 V9.0.0 (201 0-02) 

6 Specification level requirements 

6.1 Requirements 

6.1.1 General 

It is likely that only a subset of SON functions can be standardised within the timeframe of the first release of the EPS. 
For that reason a step-by-step roll out of SON functions should be provided. 

6.1 .2 SON in a Multi-Vendor network 

REQ-SON-CON-003 Self-establishment and self-optimisation shall be supported in a multiple vendor environment. 
Standardised procedures and OAM interfaces are needed to avoid cost-intensive mediation between different vendor 
nodes and side effects due to different detailed solutions (e.g. different optimisation algorithm leads to ping-pong 
effects and swinging phenomena). 

REQ-SON-CON-004 The standardised information made available to SON algorithms shall be consistent, 
independent of the vendor. 

6.1 .3 Self-Establishment of a new eNodeB 

Requirements for Self-Establishment of a new eNodeB can be found in TS32.501 [2]. 

6.1 .4 Automatic Neighbour Relation Management 

Requirements for Automatic Neighbour Relation Management can be found in TS32.51 1 [3]. 

6.1 .5 Self-Optimisation, Self-Healing, Coverage and Capacity 
Optimisation, and Handover Optimisation 

Requirements for Self-Optimisation, Self-Healing, Coverage and Capacity Optimisation, and Handover Optimisation 
can be found in TS32.521 [4]. 

6.1 .6 Continuous Optimisation due to Dynamic Changes in the Network 

REQ-SON-CNO-CON-01: An IRPManager shall be able to configure a list of valid Physical Cell Identifiers (PCI) in 
the eNB in order to allow the eNB to choose an appropriate PCI for a cell from within this list to support distributed 
PCI assignment. The list of PCIs shall be cell- specific. 

REQ-SON-CNO-CON-02: An IRPManager shall be able to configure a valid PCI in the eNB to support centralized 
PCI assignment. The PCI shall be cell-specific. 

REQ-SON-CNO-CON-03: IRP Agent shall support either the distributed or the centralized PCI assignment or both. 

REQ-SON-CNO-FUN-01: IRP Agent shall inform IRPManager about the PCI that is selected for each cell. 

REQ-SON-CNO-FUN-02: IRP Agent shall inform IRPManager about the reason for changing the PCI for a cell. 

REQ-SON-CNO-FUN-03: IRP Agent shall inform IRPManager if a valid PCI cannot be found in the list of PCIs 
configured by IRPManager. 
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6.2 Actor roles 

Actors for Self-Establishment of new eNodeBs can be found in TS32.501 [2]. 

Actors for Automatic Neighbour Relation Management can be found in TS32.51 1 [3]. 

Actors for Self-Optimisation, Self-Healing, Coverage and Capacity Optimisation, and Handover Optimisation can be 
found in TS32.521 [4]. 



6.3 



Telecommunications resources 



Telecommunications resources for Self-Establishment of new eNodeBs can be found in TS32.501 [2].. 

Telecommunications resources for Automatic Neighbour Relation Management can be found in TS32.511 [3]. 

Telecommunications resources for Self-Optimisation, Self-Healing, Coverage and Capacity Optimisation, and 
Handover Optimisation can be found in TS32.521 [4]. 



6.4 



Use cases 



6.4.1 SON in a Multi-Vendor network 



6.4.1.1 



Use Case Replacement of eNodeB of Vendor A with one of Vendor B. 



Use case stage 


Evolution/Specification 


«Uses» 
Related use 


Goal 


Seamless replacement of eNodeB from one vendor with that from another. 
Standardised procedures and OAM interfaces are needed to avoid cost- 
intensive mediation between different vendor nodes and side effects due to 
different detailed solutions. No adaptaption of the Input data to the SON 
functions is necessary due to the replacement of the eNodeB of Vendor A with 
eNodeB of Vendor B. 




Actors and 
Roles 


The Network Operations personnel periodically monitor the automatically 
updated SON information, eNodeB performance, and Network Evolution Plan 
and verify that a particular eNodeB is to be replaced. 
SON Functions - automatically generating SON outputs for automatic use 
during closed loop operation. 




Telecom 
resources 


Network Management System 

SON function. 

eNodeB 




Assumptions 


Initial SON information is defined manually by the network operator and is 
resident on the eNodeB from Vendor B. 




Pre-conditions 


The SON function is activated on the eNodeB of a Vendor A 
The SON function operates in a closed-loop mode. 




Begins when 


The eNodeB of vendor A is identified for replacement by the Network Operator. 




Step 1 (M) 


The eNodeB of vendor Vendor B is physically installed in the Network 
Operators network. 




Step 2 (M) 


The eNodeB of vendor B is Self-established. The procedure is described in [2]. 
The eNodeB of vendor B is Self-configured. The procedure is described in [2] 


REQ-SON- 
CON-03[1] 


Step 3 (M) 


Further SON functions are activated on the eNodeB. 




Ends when (*) 


The eNodeB of Vendor B is connected to the operators network and traffic is 
cutover to it from the eNodeB of Vendor A. The SON functions are operating, 
reliably producing appropriate information that results in expected network 
performance. 


REQ-SON- 
CON-04[1] 


Exceptions 






Post-conditions 


The eNodeB of Vendor B is operating. The SON function is in use and is 
automatically producing appropriate SON information. 




Traceability (*) 


Requirements or use case exposed by the use case. 


REQ-SON- 
CON-04[1] 
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6.4.2 Self-Establishment of a new eNodeB 

Specific use cases for Self Establishment of a new eNodeB can be found in TS32.501 [2]. 

6.4.3 Automatic Neighbour Relation Management 

Specific use cases for Automatic Neighbour Relation Management can be found in TS32.51 1 [3]. 

6.4.4 Self-Optimisation 5 Self-Healing 5 Coverage and Capacity 
Optimisation, and Handover Optimisation 

Specific use cases for Self-Optimisation, Self- Healing, Coverage and Capacity Optimisation, and Handover 
Optimisation can be found in TS32.521 [4], 

6.4.5 Continuous Optimisation due to Dynamic Changes in the Network 
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